In an effort to prevent attacks from being launched via its iMessage feature, Apple has debuted a security service called BlastDoor in iOS 14, its current mobile operating system version.
First detailed in an analysis this week by Google Project Zero’s Samuel Groß, BlastDoor acts as a “tightly sandboxed” service that is responsible for “almost all” of the parsing of untrusted data in iMessages.
The service comes on the heels of a recently uncovered iMessage zero-click exploit, which was being leveraged in an espionage attack against Al Jazeera journalists and executives. Citizen Lab, who disclosed the campaign in December, at the time said it did not believe that the exploit works against iOS 14, as it “includes new security protections.”
However, what those specific protections were remained unknown until Groß’s analysis this week. Groß was able to perform reverse-engineering in order to analyze the new service, using an M1 Mac Mini running macOS 11.1, and verifying his findings by applying them to iOS 14.3 (running on an iPhone XS),
“Overall, these changes are probably very close to the best that could’ve been done given the need for backwards compatibility, and they should have a significant impact on the security of iMessage and the platform as a whole,” said Groß on Thursday. “It’s great to see Apple putting aside the resources for these kinds of large refactorings to improve end users’ security.”
What is BlastDoor?
BlastDoor has two important security implications.
First, the service allows sandboxing rules to be applied across the pipeline when a message is received on a phone. This means that when a message is received, the processes on the backend execute code separately from the operating system. Only two processes (IMTransferAgent, which handles message file transfers, and apsd, Apple’s Push Notification Service daemon) are required to perform network operations.
Groß said the sandbox profile of BlashDoor is “quite tight,” with almost all file system interactions being blocked, outbound network access being denied, and any interaction with IOKit drivers being forbidden. IOKit allows the access of hardware devices and drivers for various apps and services, and is historically a big source of vulnerabilities.
This secure environment means that any malicious code sent by attackers via iMessage is prevented from accessing user data or interacting with other parts of the operating system.
Second, BlastDoor is written in Swift, which is a memory-safe language. Groß said that Swift makes it “significantly” harder to introduce memory-corruption vulnerabilities into the code base. That’s because Swift has various features to make sure variables are initialized before they’re used, memory isn’t accessed after it’s been deallocated, and array indices are checked for out-of-bounds errors.
A New Message-Parsing Process
In previous versions of iOS, when a message was sent, the parsing would occur in the Instant Messaging Agent (imagent). To parse a message in imagent, the binary data would first be decompressed; then the plist (also known as property list; an extension used to save preferences of applications) would be decoded from its binary serialization format. The various fields would be extracted to ensure they have the correct type; and finally, the `x` field content of the iMessage format would be decoded using an XML decoder. If an iMessage contained an attachment, additional steps would also be taken for parsing.
In iOS 14, this process has been moved to the new BlastDoor service. The main processing flow still begins in imagent – which receives the raw payload bytes, but then the messages are forwarded to the BlastDoor service (through +[IMBlastdoor sendDictionary:withCompletionBlock:]). Inside BlastDoor, the processes of both parsing messages and attachments mostly occur in BlastDoor.framework and MessagesBlastDoorService, said Groß.
Groß noted that one side effect of this new processing pipeline is that imagent can now detect when an incoming message caused a crash in BlastDoor – and appears to be informing Apple’s servers about such events.
“It is unclear what the purpose of this is without access to the server’s code,” said Groß. “While these notifications may simply be used for statistical purposes, they would also give Apple a fairly clear signal about attacks against iMessage involving brute-force and a somewhat weaker signal about any failed exploits against the BlastDoor service.”
Other iOS 14 Protections
In addition to BlastDoor, Groß shed light on two other significant security protections that were built into iOS 14, which was released to the public in September.
First, Apple has fixed an issue with the shared cache region of its address space layout randomization (ASLR) that was posing an architectural weakness. The weakness stemmed from the shared caches region only randomizing per boot – meaning it would stay at the same address across all processes. This could have allowed attackers to infer the base address of the shared cache and break ASLR – potentially setting them up to launch zero-click attacks.
BlastDoor’s message parsing process (click to enlarge). Credit: Google Project Zero
Apple has now added logic to specifically detect this kind of attack. Now, shared cache is re-randomized for the targeted service during the next time it is started, rendering this type of attack ineffective.
“This should make bypassing ASLR in a 0-click attack context significantly harder or even impossible (apart from brute force) depending on the concrete vulnerability,” said Groß.
Second, the BlastDoor and imagent services are now subject to a newly introduced “exponential throttling mechanism” enforced by launchd, Apple’s operating system service management daemon. With this new mechanism, if a crash occurs on the device, the intervals between restarts after the crash double with every subsequent crash (leading to an interval maxing out at 20 minutes, Groß found).
“With this change, an exploit that relied on repeatedly crashing the attacked service would now likely require in the order of multiple hours to roughly half a day to complete instead of a few minutes,” said Groß.
Apple Security Woes
Apple, historically known for its strong security posture, has faced various issues over the past few months – including the release of an emergency update this week to patch three zero-day vulnerabilities discovered in iOS.
Zero-click attacks run automatically without any user interaction and are of particular worry. Researchers in August uncovered a zero-click macOS exploit chain that could allow attackers to deliver malware to macOS users using a Microsoft Office document with macros.
Groß applauded Apple’s offensive security work reflected in the recent changes, particularly for its impact against message-based zero-click attacks.
“Not just single bugs were fixed, but instead structural improvements were made based on insights gained from exploit development work,” he said.
Threatpost has reached out to Apple for further comment.
Download our exclusive FREE Threatpost Insider eBook Healthcare Security Woes Balloon in a Covid-Era World , sponsored by ZeroNorth, to learn more about what these security risks mean for hospitals at the day-to-day level and how healthcare security teams can implement best practices to protect providers and patients. Get the whole story and DOWNLOAD the eBook now – on us!
